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ABSTRACT 

We present a new method purity analysis for Java programs. 
A method is pure if it does not mutate any location that ex- 
ists in the program state right before method invocation. 
Our analysis is built on top of a combined pointer and es- 
cape analysis for Java programs and is capable of determin- 
ing that methods are pure even when the methods do heap 
mutation, provided that the mutation affects only objects 
created after the beginning of the method. 

Because our analysis extracts a precise representation of 
the region of the heap that each method may access, it is 
able to provide useful information even for methods with 
externally visible side effects. In particular, it can recog- 
nize read-only parameters (a parameter is read-only if the 
method does not mutate any objects transitively reachable 
from the parameter) and safe parameters (a parameter is 
safe if it is read-only and the method does not create any 
new externally visible paths in the heap to objects transi- 
tively reachable from the parameter). The analysis can also 
generate regular expressions that characterize the externally 
visible heap locations that the method mutates. 

We have implemented our analysis and used it to ana- 
lyze several data structure implementations. Our results 
show that our analysis effectively recognize a variety of pure 
methods, including pure methods that allocate and mutate 
complex auxiliary data structures. Even if the methods are 
not pure, our analysis can provide information which may 
enable developers to usefully bound the potential side effects 
of the method. 
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1. INTRODUCTION 

Methods in object-oriented languages often update the 
objects that they access, including the "this" /"self" ob- 
ject. Accurately characterizing these updates is important 
for many tasks. Many program analyses, for example, need 
to understand how the execution of invoked methods may 
affect the information that the analysis maintains [15,17,20]. 
Accurate side effect information is also useful for program 
understanding and documentation [16,23]. The knowledge 
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that a method is pure, or has no externally visible side ef- 
fects, is especially useful because it guarantees that invo- 
cations of the method will not inadvertently interfere with 
other computations. Researchers in a variety of fields have 
identified method purity as a useful concept. For example, 
when model checking Java programs [10, 11,35], it is impor- 
tant to know that methods are pure because this informa- 
tion allows the model checker to reduce the search space by 
removing irrelevant interleavings. 

This paper presents a new method purity analysis for Java 
programs. This analysis is built on top of a combined pointer 
and escape analysis that accurately extracts a representa- 
tion of the region of the heap that each method may access. 
Our analysis conservatively tracks object creation, updates 
to the local variables and updates to the object fields. This 
information enables our analysis to distinguish objects allo- 
cated within the computation of the method from objects 
that existed before the method was invoked. It also allows 
the analysis to recognize captured objects whose lifetime is 
contained within the lifetime of their allocating method. 

Therefore, our analysis can check that a method is pure, 
in the sense that it does not mutate any object that exists in 
the pre-state, i.e., the program state right before the method 
invocation; this is also the definition of purity adopted in 
the Java Modeling Language [23]. This definition allows 
a method to perform mutation on newly allocated objects 
and/or construct objects and return them as a result. 

Our analysis applies a more flexible purity criterion than 
previously implemented purity analyses, e.g., [8], that con- 
sider a method to be pure only if it does not perform any 
writes on heap locations at all, and does not invoke any 
impure method. The increased precision of our analysis 
enables pure methods to use important programming con- 
structs such as iterators and complex auxiliary data struc- 
tures. 



Purity Generalizations 

Even when a method is not pure, it may have some useful 
generalized purity properties. For example, our analysis can 
recognize read-only parameters; a parameter is read-only if 
the method does not write the parameter or any objects 
reachable from the parameter. It can also recognize safe 
parameters; a parameter is safe if it is read-only and the 
method does not create any new externally visible paths in 
the heap to objects reachable from the parameter. 

The read-only and safe parameter properties do not con- 
sider the (unknown) aliasing from the calling context. E.g., 
if a method is invoked in a context where a read-only pa- 
rameter is aliased with a non-read-only parameter, mutation 



can occur on the object pointed to by the read-only param- 
eter, through the non-read-only alias. This is the common 
approach in detecting and specifying read-only annotations 
for Java [2]. 

A program verifier should use both the safe parameter 
information inferred by the analysis and the aliasing infor- 
mation at the call site. Here is an example scenario: a type- 
state checker, e.g., [15], is a tool that tracks the typestate 
of objects; one important application is checking complex, 
finite state machine-like API usage protocols. The typestate 
checker can precisely track only the state of the objects for 
which all aliasing is statically known. Each time such an ob- 
ject is passed as a safe parameter, the typestate checker can 
rely on the fact that the method call does not change the 
state of the object, and it does not introduce new aliasing 
to the object. As the typestate checker knows all aliasing 
to the tracked object, it can check that the tracked object 
is not aliased with any object transitively reachable from a 
non-safe argument at the call site. This example illustrates 
the use of safe parameter information for increasing the ef- 
fectiveness of other static analyses. 

Finally, our analysis is capable of generating regular ex- 
pressions that completely characterize the externally visible 
heap locations that a method mutates. These regular ex- 
pressions identify paths in the heap that start with a pa- 
rameter or static class field and end with a potentially mu- 
tated object field. This side effect information can provide 
many of the same benefits as a purity analysis because it 
enables other program analyses and developers to usefully 
bound the potential effects of the method. 

Contributions 

This paper makes the following contributions: 

• Purity Analysis: We present a new analysis for find- 
ing pure methods in unannotated Java programs. Un- 
like previously implemented purity analyses, we track 
variable and field updates, and allow mutations on 
newly allocated data structures. Our analysis there- 
fore supports the use of important programming con- 
structs such as iterators in pure methods. 

• Supporting Pointer Analysis: We show how to 
place this purity analysis on top of an underlying 
pointer analysis. We use an updated version of the 
Whalcy and Rinard pointer analysis [36] . The updated 
version retains the ideas of the original analysis, but 
is better structured in order to allow the analysis cor- 
rectness proof from [31]. 

• Experience: We present our experience using our 
analysis to find pure methods in a number of bench- 
mark programs. We found that our analysis was able 
to recognize the purity of methods that 1) were known 
to be pure, but 2) were beyond the reach of previously 
implemented purity analyses because they allocate and 
mutate complex internal data structures. 

• Read-Only/Safe Parameters: Our analysis detects 
read-only parameters; the execution of the method 
does not mutate objects reachable from these param- 
eters. The analysis can also detect safe parameters, 
i.e., read-only parameters such that the execution of 
the method does not produce any new externally vis- 
ible heap paths to the objects reachable from these 
parameters. 



• Write Effect Inference: We show how to use the 

results of our analysis to generate regular expressions 
that conservatively approximate heap paths to all ex- 
ternally visible locations that an impure method mu- 
tates. 

Paper Structure: Section 2 illustrates the execution of our 
analysis on an example. Section 3 presents the mathematical 
notations we use in this paper, and Section 4 describes the 
representation of the analyzed programs. Section 5 gives 
a formal presentation of our analysis, and Section 6 shows 
how to interpret the analysis results. Section 7 presents 
experimental results. Section 8 discusses some related work, 
and Section 9 concludes. 

2. EXAMPLE 

2.1 Example Overview 

Figure 1 presents sample Java source code that imple- 
ments a singly linked list in class List; the list implemen- 
tation uses list cells of class Cell. Our lists support two 
operations: add(e) adds object e to a list, and iterator() 
returns an iterator over the list elements. 1 We also define 
a class Point for modeling bidimensional points, and two 
static methods that process lists of Points. Main.sumX(list) 
returns the sum of the x coordinates of all points from list, 
and Main.f lipAll(list) flips the x and y coordinates of all 
points from list. 

Method sumX iterates over all the list elements, by repeat- 
edly invoking the next() method on the list iterator. The 
method next() is impure, because it mutates the state of 
the iterator; in our implementation, it mutates the field 
cell of the iterator. However, the iterator is an auxil- 
iary object that did not exist at the beginning of sumX. 
As we present in this section, our analysis is able to in- 
fer that sumX is pure, in spite of the mutation on the it- 
erator. Our analysis is also able to infer that the impure 
method f lipAll mutates only locations that are accessible 
in the prestate 2 along paths that match the regular expres- 
sion list .head. next* .data. (x| y) . 

2.2 Intuitive Description of the Analysis 

For each method m and for each program point inside 
m, the analysis computes a points-to graph that models the 
part of the heap that the method m accesses up to that 
program point. The nodes from the points-to graphs model 
heap objects: the inside nodes model the objects created by 
the analyzed method, the parameter nodes model the objects 
passed as arguments, and the load nodes model the objects 
read from outside the method. The analysis uses edges to 
model heap references; each edge is labeled with the field 
it corresponds to. We write (n\,f,n2) to denote an edge 
from m to 712, labeled with the field /; intuitively, this edge 
models a reference from an object that n\ models to a node 
that ri2 models, along field /. The analysis uses two kinds 
of edges: the inside edges model the heap references created 
by the analyzed method, while the outside edges model the 
heap references read by the analyzed method from escaped 
objects. An object escapes if it is reachable from outside 
the analyzed method (e.g., from one of the parameters); 



Normally, the classes Cell and Listltr would be implemented as 
inner classes of List; for simplicity, our examples uses a flat format. 

We use the term prestate to denote the state of the program right 
before the execution of an invoked method. 



1 


class List { 




2 


Cell head = null; 




3 


void addCObject e) { 




4 


head = new CellCe, head); 




5 


} 




6 


Iterator iteratorO { 




7 


return new Listltr(head) ; 




8 


} 




9 


} 




10 






11 


class Cell { 




12 


CelKObject d, Cell n) { 




13 


data = d; next = n; 




14 


} 




15 


Object data; 




16 


Cell next ; 




17 


} 




18 






19 


interface Iterator { 




20 


boolean hasNextO; 




21 


Object next ; 




22 


} 




23 






24 


class Listltr implements Iterator { 




25 


ListltrCCell head) { 




26 


cell = head; 




27 


} 




28 


Cell cell; 




29 


public boolean hasNextO { 




30 


return cell != null; 




31 


} 




32 


public Object next() { 




33 


Object result = cell. data; 




34 


cell = cell. next; 




35 


return result ; 




36 


} 




37 


} 




38 






39 


class Point { 




40 


Point (float x, float y) { 




41 


this.x = x; this.y = y; 




42 


} 




43 


float x, y; 




44 


void flipO { 




45 


float t=x; x=y; y=t; 




46 


} 




47 


} 




48 






49 


class Main { 




50 


static float sumXCList list) { 




51 


float s = 0; 




52 


Iterator it = list . iteratorO ; 




53 


whileCit .hasNextO) { 




54 


Point p = (Point) it.nextO; 




55 


s += p.x; 




56 


} 




57 


return s ; 




58 


} 




59 






60 


static void flipAlKList list) { 




61 


Iterator it = list . iteratorO ; 




62 


whileCit .hasNextO) { 




63 


Point p = (Point) it.nextO; 




64 


p.flipO; 




65 


} 




66 


} 




67 






68 


public static void mainCString args [] ) 


{ 


69 


List list = new ListO; 




70 


list.addCnew Point(l,2)); 




71 


list.addCnew Point(2,3)); 




72 


sumX(list) ; 




73 


flipAll(list); 




74 


} 




75 


} 





Figure 1: Sample Code for Section 2. 
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Figure 2: Analysis results for two simple methods: 
the constructors of Point and Cell. In each case, 
we present the points-to graph at the end of the 
corresponding method, and the set W of externally 
visible modified abstract fields. 



otherwise, the object is captured. An outside edge always 
ends in a load node. 

For each method, the analysis also computes a set of mod- 
ified abstract fields. An abstract field is a field of a specific 
node, i.e., a pair of the form (n,f). 

The analysis examines methods starting with the leaves 
of the call graph. The analysis examines each method m 
without knowing m's calling context; instead, the analysis 
computes a parameterized result that it later instantiates to 
take into account the aliasing relation at each call site that 
may invoke m. 

Section 5 contains a complete, formal presentation of the 
analysis. 

2.3 Analysis of the Example 

Figure 2. a presents the analysis results for the constructor 
of the class Point. The analysis uses the parameter node PI 
to model the object that the parameter this points to. The 
analysis records the fact that the Point constructor mutates 
fields x and y of the parameter node PI. 

Figure 2.b presents the analysis results for the constructor 
of the class Cell. The analysis uses the parameter nodes P2, 
P3, and P4 to model the objects that the three parameters, 
this, d, and n, point to. The analysis uses inside edges to 
model the references that the Cell constructor creates from 
P2 to P3 and P4. The constructor of Cell mutates the fields 
data and next of the parameter node P2. 

Figure 3.c presents the analysis results for the method 
List.add(0bject e). The method reads the head field of 
the this parameter. The analysis does not know what 
this.head points to in the calling context. Instead, the anal- 
ysis uses the load node LI to model the loaded object and 
adds the outside edge (P5, head, LI). Next, the method al- 
locates a new Cell, that we model with the inside node 
II, and invokes the cell constructor with the arguments II, 
P6, and LI. Based on the points-to graph before the call, 
and the points-to graph for the invoked constructor (Fig- 
ure 2.b), the analysis maps each parameter node from the 
Cell constructor to one or more corresponding nodes from 
the calling context. In this case, P2 maps to (i.e., stands for) 
II, P3 maps to P6, and P4 maps to LI. The analysis uses the 
node mapping to incorporate information from the points-to 
graph of the Cell constructor: the inside edge (P2, data, P3) 
translates into the inside edge (II, data, P6). Similarly, we 
have the inside edge (II, next, LI). As PI stands for II, the 
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Figure 3: Analysis results for several other simple 
methods. We use the same conventions as in Fig- 
ure 2. In addition, we use an asterisk ("*" ) to 
mark nodes returned from the analyzed method. 



analysis knows that the two fields of II are mutated. How- 
ever, II represents a new object, that did not exist in the 
prestate; hence, we can ignore the mutation of II. Finally, 
the analysis adds an inside edge from P5 to II, and records 
the mutation on the field head of P5. 

Similarly, the analysis examines four other simple meth- 
ods and obtains the information from parts d, e, f and g of 
Figure 3. 

The analysis of method Main.sumX(list) starts with for- 
mal parameter list pointing to the corresponding param- 
eter node P12. The method sumX calls list.iterator() to 
obtain an iterator over the list. The analysis takes the anal- 
ysis result for the iterator() method (Figure 2.g), maps 
Pll to P12, and produces the points-to graph after the call, 
shown in the lower half of Figure 4.h. The local variable 
it points to the node 12 returned from iterator(). Next, 
the analysis iterates over the loop from lines 53-56 until it 
reaches a fixed point. 

Figure 4 presents the inter-procedural analysis for the call 
to next(), in the first iteration over the loop body. Initially, 
the analysis maps the parameter node P10 to the actual ar- 
gument 12. The analysis matches the callee outside edge 
(P10, cell,L3) with the inside edge (12, cell, L6) from be- 
fore the call, and maps L3 to L6. This ilustrates a key 
element of our analysis: maching outside edges (read op- 
erations) against inside edges (write operations) to detect 
the nodes that load nodes stand for. Figure 4.i presents 
the points-to graph after the call: the outside edges from 
L3 generated two outside edges from L6; we also put local 
variable p to point to the returned node L4. The analysis 
detects the mutation on (12, cell), but, as usual, it ignores 



The attentive reader may be confused by the absence of an outside 
edge from 12 in Figure 4.i. The inter-procedural analysis is more 
complex than we present in this simple example. In particular, as 
we explain in Section 5.3, the inter-procedural analysis has an in- 
ternal step that simplifies the resulting points-to graph by removing 
unnecessary edges and nodes. 
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Figure 4: Inter-procedural analysis for the call to 
Listltr. next from line 54, in the first iteration over 
the loop from lines 53-56. 



all mutation on inside nodes. Section 5.3 contains a com- 
plete, formal presentation of the inter-procedural analysis. 

Figure 5 presents the inter-procedural analysis for the call 
to next(), in the second iteration over the loop body. The 
analysis proceeds as in the first iteration, except that we 
now have more edges and mappings. Figure 5.k presents the 
resulting points-to graph after the call. As L3 maps to L5 
(among other nodes), the callee outside edge (L3,next,L5) 
generates the "loop" outside edge (L5, next, L5). Loop edges 
occur during the analysis of methods that construct/traverse 
recursive data structures. 

Future iterations over the loop body do not produce new 
information. The analysis of Main. flipAll (list) proceeds 
almost identically to the analysis of Main.addX(list), ob- 
tains the same points-to graphs, but detects mutations on 
the fields x and y of the node L4. 

2.4 Analysis Results 

For the method Main.sumX, the analysis did not detect 
any mutation on the only parameter node P12, or on any 
of the load nodes reachable from it. Therefore, the analysis 
guarantees that the method sumX is pure. On the other 
hand, the analysis detects that the method Main.flipAll 
is not pure, due to the mutations on the node L4 that is 
transitively loaded from the parameter P12. In addition, the 
analysis is able to conservatively describe the set of modified 
locations. 

In the points-to graph from Figure 5.k, the outside edges 
model the references read from nodes reachable from the 
parameters. Furthermore, as the method f lipAll does not 
create any head, next, and data references, it reads only 
references that exist in the prestate. Therefore, to describe 



' ^ cell , ~ . data / "" .* 

'P10J >- L3 N *\L4) 

>, -^ 

next 




allee Listltr.next 
sumX before call 



list -*~(P12). ^ \ \ 



head^ data X_ 




j. Node Mapping. 





_ 








list 


-*-^>12 


)^ 




P 




f^ 


head v 
cell 




data ^> - 

--— » 

r 


it 


-^3 


cell 


next 


^ / data 
*^L5)T >next 



k. Points- To Graph After the Call. 

Figure 5: Inter-procedural analysis for the call to 
Listltr.next from line 54, in the second iteration 
over the loop from lines 53-56. 



the set of locations that the method flipAll modifies, it 
suffices to describe the paths from P10 (the only param- 
eter) to L4, along outside nodes. These paths are gener- 
ated by the regular expression head. next*. data. Hence, 
f lipAll may modify only the prestate locations reachable 
along a path that matches list .head. next*. data. (x|y). 
Section 6.2 explains how to compute the regular expressions 
automatically. 

2.5 Using the Analysis Results 

Knowing that Main.sumX(list) is pure allows us to propa- 
gate information about list across calls to Main.sumX(list). 
It also allows us to freely use sumX in assertions and specifi- 
cations. 

Even if Main.flipAll(list) is impure, we know that it 
modifies only locations covered by heap paths that match 
the regular expression list .head. next*. data. (x|y). 
Therefore, we can still propagate information across calls to 
f lipAll, as long as the information refers only to other lo- 
cations. For example, as none of the list cells matches the 
aforementioned regular expression (by a simple type reason- 
ing), the list spine itself is not affected, and we can propagate 
non-emptyness of list across calls to f lipAll. 

3. GENERAL MATHEMATICAL NOTATIONS 

This paper uses the following notations: "{ao, ai, . . . , a^}" 
represents the set of distinct elements ao, oi, ■ ■ ■ , fflfc; de- 
notes the empty set and l+l denotes the disjoint set union 
operator. For any set A, V(A) is the set of all subsets of A, 
i.e., V(A) = {B | B C A}, "{at i— » bi} ie i" denotes a partial 
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4. PROGRAM REPRESENTATION 

We present our analysis in the context of a small but non- 
trivial subset of Java. It is straightforward to extend the 
analysis to handle the full Java language. 

A program consists of a set of classes, Class, and a set 
of methods, Method. Each method has a list of parame- 
ters, a set of local variables, and a body consisting of a 
list of instructions. Method m has k — arity(m) param- 
eters: Po,Pi, ■ ■ ■ , Pfc-i; the first parameter po is the "this" 
parameter. Var denotes the set of all local variables and 
parameters. For simplicity, we suppose that all parameters, 
local variables, object fields and return values have object 
type; in the analysis implementation, it is straightforward to 
ignore parameters, local variables, etc. of primitive values. 

Each class C G Class has a set of fields fields(C) = 
{/o,/i, . • • ,f q -i}. Some fields are static, i.e., attached to 
a class C, not to a specific instance of C; static fields act 
as global variables. We distinguish between static and non- 
static fields by using different instructions for manipulating 
them. 

Figure 6 presents the statements from the programs we 
analyze. We suppose that prior to the analysis, each appli- 
cation is preprocessed to contain only these statements. 

An IF instruction may alter the normal control flow by 
branching to a specific address in the same method. A CALL 
instruction u vr = Vo.s(. . . )" calls the method named s from 
the class C of the object pointed to by vo- The parame- 
ter passing semantics is call-by-value. Although we did not 
give any mechanism for calls to native methods, the analy- 
sis handles the more general case of unanalyzable calls, i.e., 
calls to methods whose code is unavailable or too expensive 
to analyze. 

In Java, threads are instances of the class 
Java. lang. Thread; a thread is started by calling a special 
native method (java.lang.Thread.start()) on the thread 
object. The body of the newly started thread is the run 
method of the thread object. Equivalently, in our language, 
we start a thread by executing the THREAD START in- 
struction "start v" ■ 

CFGm denotes the control flow graph of method m. CFG m 
contains an arc from label lb\ to label lb-2 for every lb\ and 
Z&2 that might be consecutive on an execution path inside 
method m. CFGm has an isolated entry point entry m , and 
a single exit point exit m - Given a label lb from a method 
to, pred(lb) is the set of direct predecessors of lb in CFG m , 
and succ(lb) is the set of direct successors of lb in CFG m . 

We assume that we have a conservative call graph CG: 
for a given CALL at label lb, CG(lb) contains all methods 
that may be called by that CALL. 

In our representation, exceptions are handled explicitly: 
e.g., there is a null pointer check before each pointer deref- 
erence; if we detect an exceptional condition, we allocate 
an appropriate exception object and we transfer the control 
to the appropriate exception handler (if any), or to the end 



Statement Name 


Statement Format 


Informal Semantics 


COPY 


Vl = V2 


copy one local variable into another 


NEW 


v = new C 


create a new object of class C; all fields of the new object are 
initialized to null 


NEW ARRAY 


v = new C[k] 


create an array of k references to objects of class C; all array 
cells are initialized to null 


STORE 


Vl •/ = V2 


store a reference into an object field 


STATIC STORE 


C.f=v 


store a reference into a static field 


ARRAY STORE 


vi[i] = V2 


store a reference into an array cell 


LOAD 


Vl = v 2 .f 


load a reference from an object field 


STATIC LOAD 


v=C.f 


load a reference from a static field 


ARRAY LOAD 


V2 = Vl[i] 


load a reference from an array cell 


IF 


if (. . .) goto a t 


conditional transfer of control to address at from the same 
method (the condition is irrelevant for our analysis; we just sup- 
pose it has no heap side effects) 


CALL 


Vr = Vo-S(vi, . . . ,Vj) 


call method named s of object pointed to by Vo 


RETURN 


return v 


return from the currently executed method with the result v 


THREAD START 


start v 


start the thread pointed to by v 



Figure 6: Relevant Statements in the Analyzed Program. 



of the current method (otherwise). There is a check after 
each call, to propage the exception thrown from the invoked 
method. 

5. ANALYSIS PRESENTATION 

The analysis processes individual methods from the ana- 
lyzed program, from the leaves of the call graph to the main 
method. During the analysis of method m, the scope of the 
analysis is the method m plus the methods it transitively 
calls. For each program point inside m, the analysis com- 
putes a points-to graph that models the heap at that point. 
More specifically, for each label lb from method m, the anal- 
ysis of m computes the points-to graph oA(lb) for the pro- 
gram point right before lb, and the points-to graph Ao(lb) 
for the program point right after lb. In addition, for each 
method m, the analysis computes the set W m that contains 
all the externally visible abstract fields mutated by m. An 
abstract field is a pair (n,f) that models a mutation of the 
field / of the parameter/load node n; since we are interested 
only in externally visible mutations, we ignore mutations on 
inside nodes (an inside node models objects allocated by the 
current invocation of the analyzed method). 

We express the analysis of method m as a set of standard 
dataflow equations: 



Gm 
init 

\J{Ao(lb') | lb' G pred(lb)} 



if lb = entry v 
otherwise 



oA(lb) = 

Ao(lb) = (lb}(oA(lb)) 

In the above equations, G™ it is the points-to graph for the 
beginning of method m, and J/6] is the transfer function 
attached to the label lb. 

Each transfer function [Z6] takes the points-to graph for 
the program point right before lb, and produces the points- 
to graph for the program point right after lb. At the begin- 
ning of the analysis of method m, W m = 0. The transfer 
function [Z6] may have the side effect of adding a few new 
elements to the set W m ■ 

The rest of this section is organized as follows. Section 5.1 
defines the abstractions used by the analysis. Section 5.2 
presents the intra-procedural analysis, i.e., the initial points- 
to graph G™ it and the transfer functions [Z6] for labels lb 



n G Node = IN ode W PNode fed LNode W {nan.} 



n\ h G INode 

n^ A 6 PNode 

nfi G LNode 



inside nodes 
parameter nodes 
load nodes 



(n,f) G AField = Node x Field; abstract fields 

I G IEdges = P(Node x Field x Node) 
O G OEdges = V(Node x Field x LNode) 
L G LocVar = Var -+ P(Node) 

G G PTGraph = IEdges x OEdgesx 
LocVar x P(Node) 



Figure 7: Sets and notations used by the analysis. 



that do not correspond to analyzable CALLs. Section 5.3 
presents the inter-procedural analysis, i.e., the transfer func- 
tions [Z6] for labels that correspond to analyzable CALLs. 
Section 5.4 gives a high-level description of an algorithm that 
computes the least fixed point of the analysis equations. 

5.1 Sets and Notations 

Figure 7 presents the sets and the notations that we use 
in the analysis presentation. 

The analysis uses nodes to model objects from the ana- 
lyzed program. We introduce one inside node n\ b for each 
label lb that corresponds to a NEW or an ARRAY NEW 
instruction. n\ b models all objects created by the analyzed 
scope by executing the instruction from label lb. 

There is one parameter node n^ j for each formal param- 
eter pi of the analyzed method m. For a given invocation 
of a method, a parameter node models a single object: the 
object pointed to by the actual argument. 

Some LOAD instructions read references from escaped ob- 
jects, i.e., objects accessible from outside the analyzed scope. 
As the analysis examines each method once, without know- 
ing its calling context, the analysis does not know what the 



other parts of the program may have written in the fields 
of the escaped objects. Instead, for each label lb that cor- 
responds to a LOAD/ARRAY LOAD statement that reads 
from escaped objects, the analysis introduces a load node 
nf b ; n\ b models the objects read at label lb from escaped 
objects. 

The parameter/load nodes are essential for our ability to 
analyze m without knowing the heap at the point where 
m is called. In the presence of complete information about 
the calling context, the inside nodes would be enough for 
modeling the heap. A parameter/load node n is a place- 
holder for the inside nodes associated with the objects that 
n models. For each call to method m, the inter-procedural 
analysis computes a node mapping that disambiguates these 
placeholders, according to the current calling context. 

The special node riGBL models objects that may be accessed 
by the entire program. We use it to model objects that are 
read from a static field and objects returned by unanalyz- 
able CALLs. 

An abstract field is a pair (n,f); it conservatively repre- 
sents the field / of all objects that n models. 

A points-to graph G £ PT Graph is a tuple G — 
(I,0,L,E), consisting of a set of inside edges /, a set of 
outside edges O, an abstract state of local variables L, and 
a set of globally escaped nodes E. 

The edges from the points-to graph model the points-to 
relation between objects. The inside edges from / model the 
heap references created by the analyzed scope. The outside 
edges from O model the heap references read by the analyzed 
scope from escaped objects. An outside edge always ends in 
a load node. 

Arrays are just a special kind of objects, and are modeled 
by nodes too. If an array has elements of a non-primitive 
type, the values stored in the array cells are addresses of 
objects. We use edges to represent these heap references. 
We do not distinguish between individual array cells: the 
special field [] represents all cells of an array. 

L models the state of the local variables of the analyzed 
method: L(v) is the set of nodes that the local variable v 
may point to. To keep track of the objects returned from 
an analyzed method m, we introduce a special variable v ret : 
L(v re t) is the set of nodes that m might return. 

The last component of a points-to graph, E, contains: 1) 
the nodes whose address is stored in static fields, 2) the 
nodes that correspond to started threads, and 3) the nodes 
passed as arguments to unanalyzable CALLs. These nodes 
escape the analyzed scope: they are potentially reachable 
from the entire program; we say that they escape globally. 

Other escaped nodes include the parameter nodes, the re- 
turned nodes, and the special node n GBL (n aBL models the ob- 
jects returned from unanalyzable CALLs and/or read from 
a static field). In addition, any node reachable from an 
escaped node along a path of inside and/or outside edges 
escapes too. Formally, 

Definition 1. Given a points-to graph G = (I , O , L , E) , 
let e(G) be the following boolean predicate on nodes: e{G){n) 
is true iff n is reachable from a node from PNodeU L(tv,rt)U 
EuIugbl}, along a (possibly empty) path of edges from IUO. 
If e(G)(n), n escapes from G . Otherwise, n is captured in 
G. 

The ordering relation between sets (e.g., I, O, E) is the 



set inclusion; the associated join operation is the set union. 
For elements from the set LocVar, we use the classic ele- 
mentwise ordering between functions: Lx C. L2 iff Vu G Var, 
Li(v) C L,2(v). The associated join operation is Lx U L2 = 
\v . (L\(v) V} L-ziv)) . Points-to graphs are ordered compo- 
nentwise: 

(Ii,Oi,L u Ei) C (h,02,L 2 ,E 2 ) iff h C h, Ox C O2, 
Li C. L2, and E\ C h\. {PTGraph, C) is a join semi-lattice 
with the join operator 

{Ix,Ox,Lx,Ex }U(I 2 ,02,L 2 ,E2} = 

{ h U I 2 , Ox U O2, L x U L 2 , Ex U E 2 ) 

and the least element -LprGraph— (0, 0, \v.%, 0). 

5.2 Intra-procedural Analysis 

The points-to graph for the beginning of m is: 

G hiit = (0' 0' {Pi ^ Hm,»}o<»<k-l, 0) 

where po, pi, ... , pu-x are the k parameters of m. Each pa- 
rameter pi points to the corresponding parameter node nf ni ; 
G™ it is otherwise empty. At the beginning of the analysis 
of m, the method- wide set W m of mutated abstract fields is 
initialized to be empty. 

Figure 8 presents the transfer functions associated with 
the labels from the analyzed program; Figure 10 presents 
an informal graphic representation for some of the transfer 
functions. 

The transfer function |/6] takes as argument the points-to 
graph for the program point just before label lb and returns 
the points-to graph for the program point right after lb. [IbJ 
may also have the side effect of adding a few new elements 
to W m , if the instruction from label lb mutates a field of one 
or more nodes. We define the functions \lb\ on a case by 
case basis, based on the instruction from label lb. Figure 8 
does not cover the case of an analyzable CALL; we study 
this case later in Section 5.3. 

As a general rule, assignments to variables are destructive, 
i.e., assigning something to v "removes" all the previous 
values of L(v), while assignments to node fields are non- 
destructive 4 : assigning something to ni./does not remove 
the existing edges that start from m. The reason is that a 
node might represent multiple objects and so, updating nx-f 
might not overwrite the edge {nx,f, TI2) because the update 
instruction and the edge might concern different objects. 

The two special labels entry m and exit m do not corre- 
spond to any concrete instruction. The transfer function for 
them is naturally the identity function. This is also the case 
for the labels that correspond to IF, or some other instruc- 
tion that does not manipulate pointers. 

A COPY instruction "vi = ^2" makes vx point to all the 
nodes that V2 might point to. As previously mentioned, the 
analysis "forgets" the previous value of L(vx). The transfer 
function for a label lb that corresponds to a NEW instruc- 
tion "v = new C" makes v point to the inside node attached 
to the label lb, n\ b . Notice that object creation does not 
generate any effect in our analysis: we are interested only in 
mutation on the objects from the prestate, i.e., objects that 
existed at the beginning of the method. 

For a STORE instruction u vx-f — %", the analysis intro- 
duces an /-labeled inside edge between each node pointed to 
by Vx, and each node pointed to by V2- The analysis also 
updates the set W m to record the mutation on the field / 
of all non-inside nodes pointed to by Vx- The case of an 



An equivalent term is "weak updates." 



Instruction from 
label lb 


[lbj({I,0,L,E)) 


Set of abstract fields 
added to W m 


Vl = V2 


{I,0,L[vi^L(v 2 )],E) 





v = new C 


{I,0,L[v^{nj b }],E} 





v = new C[k] 


{I,0,L[v^{ni}],E) 





Vl •/ = v 2 


(IU(L(vi)x{f}xL(v 2 )) ,0,L,E) 


(L(vi) \ INode) x {/} 


vi [i] = v 2 


(IU(L(vi)x{[]}xL(v 2 )) ,0,L,E) 


(L{vi) \ INode) x {[]} 


C.f=v 


(I,0,L,EUL(v)} 


{{n W L,f}} 


Vl = v 2 .f 


process Joad(G, Vi, v 2 , f, lb) 





vi = v 2 [i] 


process Joad(G, vi, v 2 , [], lb) 





v=C.f 


(I,0,L[v^{n WL }],E) 





if (. . .) goto a t 


(I,0,L,E) (unmodified) 





Vr = Vo-S(vi, . . . ,Vj) 


Case 1: analyzable call — studied later in Section 5.3. 


Case 2: unanalyzable call 

{I,0,L [v R ^ n GBL ] , E U \Ji =0 L{vi)) 





return v 


(I,0,L[v ret ^L(v)],E) 





start v 


(I,0,L,E\JL(v)) 






Figure 8: functions [Z6],Z6 £ Label. [16] takes the points-to graph G = (I,0,L,E) for the program point right 
before label lb, and produces the points-to graph for the program point after lb. See Figure 10 for an informal 
graphic representation of some of the transfer functions. 



process Joad({I, O, L, E), Vi, v 2 , f, lb) = 

let A = {n € Node j 3m € L(v 2 ),{rn,f, n) G 1} 
B = {n € L(v 2 ) | e(G)(n)} in 
if (B = 0) 

then (I, O, L [vi i-> A] , E) 

else (I, Ou(Bx{f}x {nf b }), L [vi h- (A U {n£})] , E) 



Figure 9: processdoad. Its arguments are, in order, the points-to graph before the load (G = (I,0,L,E)), 
the variable vi we load into, the variable v 2 we load from, the loaded field /, and the label lb of the LOAD 
instruction "vi — v 2 .f. It returns the points-to graph after the instruction. 



Statement Before 



After 



Vl = V 2 



Vi- 



'"■2- 



■o 

-o 



\0 



V-2- 



JO O 

where (T) is the inside node for this statement 



v = new C v 



Vi- 



0^-0 



Vl-f= V2 



V 2 



-o 



Vi- 



V2--> 




Statement Before 



After 



Vi = v 2 .f 



*-o o 

if (2) does not escape 

vi^O o 

/\ ; ''i 



if (2) escapes; (5) is the load (@l 
node for this statement 



Figure 10: Informal graphic representation of the transfer functions for non-call statements. We use con- 
tinuous circles for all types of nodes, continuous lines for the inside edges, and dashed lines for the outside 
edges. We use bold circles/lines for potentially new nodes/edges. 



ARRAY STORE instruction "vi[i] = ifc" is similar, except 
that we use the special field [] that models the references 
coming from all the cells of the array. The analysis records 
the mutation on the special field [] for all concerned nodes. 
For a STATIC STORE "C./ = v," we add all nodes pointed 
to by v to the set of globally escaped nodes E, and we record 
a mutation on the static field /. 

The transfer function for a LOAD instruction "i>i = %■/' 
uses the auxiliary function process Joad from Figure 9. After 
the instruction, v\ points to all nodes pointed to by /-labeled 
inside edges starting from nodes in L{y2)', in Figure 9, we 
collect these nodes in the set A. If we load from nodes that 
escape the analyzed scope, i.e., B 7^ in Figure 9, vi also 
points to the load node nf b . In this case, the analysis intro- 
duces an /-labeled outside edge from every escaped node we 
read from to nf . Later, when we analyze calls to m, we use 
these outside edges to detect the nodes that the placeholder 
nf b stands for. The transfer function for an ARRAY LOAD 
instruction is identical, except that it uses the special field 



Vj) v makes 



An unanalyzable CALL u Vr — vq.s{vi, 
its arguments reachable from unanalyzed parts of the pro- 
gram. Therefore, the analysis adds all nodes pointed to by 
Vo, ■ ■ ■ , Vj to E, the set of globally escaped nodes. Also, 
in the points-to graph after the unanalyzable CALL, vr 
points to the special node tigbl that models objects poten- 
tially reachable from the entire program. Similarly, for a 
START THREAD instruction "start v" , the analysis adds 
all nodes pointed to by v to E. Finally, for a RETURN in- 
struction "return v" , the special variable v re t is set to point 
to the returned nodes. 

5.3 Inter-procedural Analysis 

Consider a CALL instruction at label lb, "vr — vo.s(vi, 
..., Vj)" , and let callee G CG(lb) be one of the possible 
callees. The inter-procedural analysis uses the points-to 
graph G before the CALL and the points-to graph Gcaiiee — 
oA(exitcaiiee) for the end of callee, and computes a points- 
to graph for the program point after the CALL, valid in 
the case when callee is called. If there are several possi- 
ble callees, we conservatively join the points-to graphs com- 
puted for each of them. 

The inter-procedural analysis has four steps: 

1. We compute a mapping relation fj! C Node x Node 
that maps nodes from Gcaiiee to nodes that appear in 
the final graph; /V disambiguates as many parameter 
and load nodes as possible. 

2. We use the mapping /i' to combine G and Gcaiiee- An 
important aspect of this step is that each node n from 
Gcaiiee is projected through the mapping //, i.e., intu- 
itively, n is replaced with the nodes from /j'(n). 

3. We simplify the resulting points-to graph by removing 
superfluous load nodes and outside edges. 

4. We use the information about the abstract fields mu- 
tated by the callee (i.e., the set W callee) to update the 
set W m of abstract fields mutated by m. 

We describe these steps in the next paragraphs. 

Construction of the Node Mapping 

We start by computing a "core" mapping /i that disam- 
biguates as many parameter and load nodes from the calee as 



ni _ „ 2 




a. Constraint 2 



b. Constraint 3 for 
M(ni) n ju(n 3 ) t^0 



-»- outside edge 
-»- inside edge 



existing mapping 
new mapping 



Figure 11: Graphic representation of Constraint 2 
and Constraint 3. 



possible. Let G = (I,0,L,E), and Gcaiiee = 

(I caiiee, O callee, L ca iiee, E 'callee) ■ We define fj, as the least fixed 
point of the following constraints: 



L{Vi) C fl (n bailee, i) , Vl G {0, 1, . . . j} 

(m,/,n 2 ) G Ocaiiee, (n 3 ,/,n 4 ) G I, n 3 G M"i) 
n 4 G /i(n2) 

{fll,f, ri2) G Ocallee, (n 3 ,/, ri.4) G Icallee, 

(M(rii) u {m}) n (/j(n 3 )u{n 3 })/0, 

(m ^ n 3 ) V (ni £ LNode) 

fi(n 4 ) U ({n 4 } \ PNode) C fi(n 2 ) 



(1) 



(2) 



(3) 



Constraint 1 maps each parameter node n callefii to the 
nodes pointed to by v%, the i th argument passed to callee; 
these are the nodes from the set L(vi). The other two con- 
straints extend the mapping by matching outside edges (i.e., 
references read by LOAD instructions) against inside edges 
(i.e., references created by STORE instructions). 5 

Constraint 2 handles the case when the callee reads ref- 
erences created by the caller. It matches an outside edge 
{ni,f, U2) G Ocaiiee from the callee against an inside edge 
(n 3 ,/, 714) G / from the caller, in the case when m might 
represent n 3 , i.e., n 3 G /u(ni). Figure 11. a presents a graphic 
representation of this situation. As ni might be n 3 , the out- 
side edge read from n\ might be the inside edge (n 3 ,/, 714), 
and the load node ri2 might be the node ru. Hence, the 
analysis maps ni to 714, i.e., 714 G p-ini) 

Constraint 3 matches an outside edge from the callee 
against an inside edge from the callee, i.e., from the same 
scope. This constraint deals with the aliasing present in the 
calling context. Consider an outside edge {ni,f, n 2 ) G O ca iiee 
and an inside edge (n 3 ,/, ua) G Icallee- Figure ll.b presents 
a graphic representation of the case where n\ and n 3 might 
represent the same node 715. In this case, 112 might be n 4 . 
Therefore, we enforce n 4 G /z(ri2). Also, as n 4 is a node 
from the callee, it might be a node placeholder that repre- 
sents some other nodes. Therefore, node n 2 might represent 
not only n 4 but also the nodes represented by n 4 . The anal- 
ysis updates the mapping to record this too: fj,(n 4 ) C /j(n2). 
The same reasoning is valid if m might represent n 3 , i.e., 

A real implementation would use Constraint 1 to initialize the map- 
ping and would next iterate only over constraints 2 and 3 until a fixed 
point is reached. 



nz G fi(ni), or 713 might represent m, i.e., m £ /x(ri3). 
Constraint 3 unifies these three cases in a single condition: 

Qu(ni) u {m}) n (mM u {n 3 }) / 

The third part of the precondition, "(ni 7^ 713) V (ni G 
LNode)" , reduces the applicability of Constraint 3, and avoids 
fake mappings. The correctness proof from [31] shows that 
this condition does not prevent the analysis from detecting 
all real mappings. 

We compute the final mapping // by extending the "core" 
mapping fi with a mapping from each non-parameter node 
to itself: 

Vn, (j!(n) = n{n) U ({n} \ PNode) 

/i' maps nodes from G ca ii ee to nodes that appear in the 
points-to graph after the call. Inside nodes model objects 
created by the analyzed scope and should appear in the 
points-to graph after the call; for inside nodes, // is the 
identity relation. We already know all the nodes that the 
parameter nodes stand for. Hence, the parameter nodes 
are unnecessary in the resulting points-to graph, and the 
map extension ignores them. This is also the reason why 
in Constraint 3, instead of /j,(n4J U {ru} C /j(rt2), we use 
/x(ri4) U ({ru} \ PNode) C fi(n,2): as we do not want the 
callee parameter nodes to appear in the resulting points-to 
graph, we avoid creating mappings to them. 

Unlike parameter nodes, load nodes are generally not fully 
disambiguated. Each load node is a placeholder for the 
nodes that a specific LOAD instruction loads from an es- 
caped node. That escaped node might remain an escaped 
node even in the points-to graph after the CALL. In a first 
phase, we preserve all load nodes. We show later in this 
section how to remove some of them. 

Combining the Points-to Graphs 

After we obtain the node mapping //, we use it to com- 
bine the points-to graph G before CALL with the points-to 
graph Gcaiiee for the end of callee. We obtain the points-to 
graph after the CALL, valid if callee is called. Formally, we 
construct the points-to graph G2 = {I2, 02,L>2, E2) defined 
by the following equations: 

h = I U [J n'(ni) x {/} x M '(n 2 ) 

<«1 ,/, 712 )€i callee 

O2 = O U [J n'(n) x {/} x {n L } 

(n,f, n L)eO callee 

L 2 - L [vn i-»- n'(L caUee (Vret))] 

E2 — EU fJ, (Ecallee) 

The above equations require some explanation. The heap 
references that existed before the call might exist after the 
call too. Hence, all inside edges from G appear in the points- 
to graph after the call. In addition, if callee created the heap 
edge {ni,f, 712), where m may be any node from /_t'(ni), and 
712 may be any node from //(ri2), then callee might have 
created any of the inside edges from the set /i'(ni) x {/} x 
//(ri2). All these edges appear in the points-to graph after 
the call, as well. 

Similarly, the set of outside edges after the call is the union 
of the set of outside edges right before the call, O, and the 
semi-projection through fi' of the outside edges from the end 



of callee: we project only the start node of an outside edge, 
the target remains unmodified. Here's why: an outside edge 
(n,f,nf b ) from the callee models the action of loading the 
field / from the escaped node n, action done by the LOAD 
instruction at label lb; the load node nf b models the objects 
read in that instruction. As n may be any of the nodes from 
/_t'(n), the read operation may take place from any of these 
nodes, hence the need for projecting the node n. However, 
nf b has the same meaning: it models the objects read in the 
instruction at label lb. Hence, the analysis does not project 
n\ b through //. 

The abstract state of the local variables after the call 
is similar to the state L before the call, except that now 
vr — the local variable that receives the value returned from 
the callee — points to the nodes returned from callee, i.e., 
IJ-'{L callee (vret))- The projection is necessary because some 
of the returned nodes may be placeholders from callee that 
// disambiguates. Finally, the set of globally escaped nodes 
is the union of the set of directly escaped nodes before the 
call, E, and the set of nodes that directly escape in callee, 

M (Ecallee)- 

Points-to Graph Simplification 

We simplify the points-to graph for the program point after 
the call by removing all captured load nodes (together with 
all adjacent edges), as well as all outside edges that start in 
a captured node. 

Intuitively, a load node is a placeholder for the (unknown) 
nodes loaded from an escaped node. There is no need for a 
load node when we load from captured nodes: as only the 
analyzed scope access a captured node, the analysis knows 
all the nodes loaded from it. If a points-to graph G contains 
a captured load node nf b , all the nodes that we loaded nf b 
from 6 are captured too. Therefore, we can remove all cap- 
tured load nodes. Similarly, we can remove all outside edges 
that start from a captured node. 

Modified Abstract Fields 

We update the set W m of modified abstract fields from the 
caller m by adding to it all elements from the following set: 

[J ((//(») \ INode) n N) x {/} 

<«,/>ew ca „„ 

where N is the set of nodes that appear in the simplified 
points-to graph. We use the mapping \i! to project each node 
modified by the callee. As usual, we ignore inside nodes; we 
also use the set intersection "1*1 N" to ignore nodes that have 
been removed by the points-to graph simplification. 

5.4 Analysis Algorithm 

As we prove in [31], all transfer functions are monotonia 
For each analyzed program, the number of nodes we can 
define is bounded: we have one parameter node for each 
formal parameter, one inside node for each NEW instruc- 
tion, at most one load node for each LOAD instruction, etc. 
By consequence, PTGraph is finite and there is no infinite 
ascending chain in (PTGraph, C). Hence, we can solve the 
dataflow equations with an iterative fixed point algorithm. 

We recommend using a variant of the "Iterating Through 
Strong Components" algorithm [30, Chapter 6]. Our algo- 
rithm contains an outer loop for the inter-procedural analy- 
sis, and nested inside it, an inner loop for the intra-procedural 



D I.e., the nodes that point to n lb through some outside edge. 
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analysis. 

The inter-procedural computation processes the strongly 
connected components of the call graph, i.e., the groups 
of mutually recursive methods, 7 in increasing topological 
order, i.e., from the leaves of the call graph to the main 
method. For each such set of mutually recursive meth- 
ods, the algorithm uses a worklist to iterate over the set 
of methods until it reaches the least fixed point. At the 
beginning of the processing for a strongly connected compo- 
nent, the worklist contains all the methods from that com- 
ponent. In each iteration, the algorithm takes a method 
from the worklist and calls the inner computation, i.e., the 
intra-procedural computation, to analyze the method. If the 
points-to graph for the end of the method changed, all the 
possible callers of the method that are in the current strong 
component are added to the worklist. The inter-procedural 
computation for a component terminates when the worklist 
is empty. 

The intra-procedural computation is similar to the inter- 
procedural computation: it processes the strongly connected 
components of the control flow graph for the analyzed 
method in decreasing topological order, i.e., from the begin- 
ning of the method toward its end, and iterates over each 
component by using a worklist. 

Complexity: Let n be the size of the analyzed program. 
The analysis computes points-to graphs for 0(n) program 
points. The height of the lattice of points-to graphs is 
0{n^nf), where n a , the number of nodes, and n/, the total 
number of fields, are both 0(n). Most transfer functions can 
easily be implemented in polynomial complexity. The only 
difficult operation is the construction of the inter-procedural 
node mapping. However, notice that the inter-procedural 
analysis monotonically computes mappings of at most n„ el- 
ements. Therefore, the worst-case complexity is big, at least 
0(nn^nf), but still polynomial in the size of the program. 
In practice, we have used this pointer analysis to analyze all 
SpecJVM applications, stack allocate captured objects, and 
remove synchronization on thread-local objects [36]. 

6. USE OF ANALYSIS RESULTS 

After the analysis terminates, for each analyzable method 
m, we can use the points-to graph G — {I,0,L, E) for the 
end of m, and the set W m of modified abstract fields to infer 
method purity, write effects, read-only parameters and safe 
parameters. We explain each such application in the next 
paragraphs. 

6.1 Method Purity 

To check whether m is pure, we compute the set A of 
nodes that are reachable in G from parameter nodes, along 
outside edges. We also compute the set B of all globally 
escaped nodes, i.e., nodes that are reachable from Eu{iigbl}; 
these are the nodes that are potentially reachable, and hence 
mutated, from the entire program, e.g., by native methods, 
hemce, we cannot guarantee anything about them. 

The method m is pure iff for any node n € A, 1) n does 
not escape globally (n ^ B) and 2) no field of n is mutated, 
i.e., there is no field /such that (n,f) £ W m - 

For constructors, we can follow the JML convention of 
allowing a pure constructor to mutate fields of the "this" 
object: it suffices to ignore all modified abstract fields for 
the parameter node ri^fi that models the "this" object. 

In practice, many of these groups are singletons. 



6.2 Write Effects 

We can infer regular expressions that describe all the 
prestate locations modified by m as follows: we construct 
a finite state automaton F with the following states: 1) all 
the nodes from the points-to graph G, 2) an initial state 
s, and 3) an accepting state t. Each outside edge from G 
generates a transition in F, labeled with the field that labels 
the outside edge. For each parameter pi of m, we create a 
transition from s to the corresponding parameter node, and 
label it with the parameter pi. Also, if 71gbl appears in G, 
we create a transition from s to w-gbl and label it with the 
empty string. 8 For each mutated abstract field {n,f), we 
add a transition from n to the accepting state t, and label 
it with the field /. 

In addition, for each globally lost node n (see above), we 
add a transition from n to t, and label it with the special 
field REACH. If P is a heap path (i.e., a series of fields, 
separated by dots, starting in a parameter or a static field), 
P.REACH matches all objects that are transitively reachable 
from an object that matches P. 

The regular expression that corresponds to the constructed 
automaton F describes all modified prestate locations. We 
can use automaton-minimization algorithms to try to reduce 
the size of the generated regular expression. 

Note: The generated regular expression is valid if G does 
not contain an inside edge and a load edge with the same 
label. This condition guarantees that the heap references 
modeled by the outside edges exist in the prestate (the regu- 
lar expressions are supposed to be interpreted in the context 
of the prestate). An interesting example that exhibits this 
problem is presented in [32] . If this "bad" situation occurs, 
we conservatively generate a regular expression that covers 
all nodes reachable from all parameters, with the help of the 
REACH field. In practice, we found that this case is very 
rare: most of the methods do not read and mutate the same 
field. 

6.3 Read-Only Parameters 

A parameter pi is read-only iff none of the locations tran- 
sitively reachable from pi is mutated. To check this, we 
compute the set Si that contains the corresponding param- 
eter node n^i, and all the load nodes reachable from n„ i 
along outside edges. Parameter pi is read-only iff there is 
no abstract field (n,f) £ W m such that n G Si. 

6.4 Safe Parameters 

A parameter is safe if it is read-only and the method m 
does not create any new externally visible heap paths to an 
object transitively reachable from the parameter. 

Suppose Pi is a read-only parameter. To detect whether pi 
is also safe, we compute, as before, the set Si that contains 
the corresponding parameter node n mj ,, and all the load 
nodes reachable from n^ » along outside edges. Because pi 
is a read-only parameter, none of the nodes from Si escapes 
globally or is mutated. 

We also compute the set S2 of nodes reachable from the 
parameter nodes and/or from the returned nodes, along in- 
side/outside edges. Notice that S2 contains all those nodes 
from G that may be reachable from the caller after the end 
of m. Therefore, to create a new externally visible path to 
an object transitively reachable from pi, one needs to create 
an edge that starts in an object modeled by a node from S2 

In an automaton, such a transition can always be performed, without 
consuming any input. 
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and ends in an object modeled by a node from Si. Hence, 
parameter pi is safe if there is no inside edge from a node in 
52 to a node in Si. 

7. EXPERIENCE 

7.1 Implementation 

We implemented our analysis in the MIT Flex compiler 
infrastructure [1], a static compiler for Java bytecode. To in- 
crease the analysis precision (i.e., prevent edges that do not 
correspond to any heap references), we manually provide the 
points-to graphs for several common native methods. Also, 
we attach type information to nodes, in order to prevent 
type-incorrect edges, and avoid inter-procedural mappings 
between nodes of conflicting types. 

7.2 Checking Purity of Data Structure 
Consistency Predicates 

We ran our analysis on several benchmarks borrowed from 
the Korat project [3,27]. Korat is a tool that generates non- 
isomorphic test cases up to a finite bound. Korat 's input 
consists of 1) a type declaration of a data structure, 2) a 
Unitization (e.g., at most 10 objects of type A, and 5 objects 
of type B), and 3) repOk, a pure boolean predicate written 
in Java that checks the consistency of the internal repre- 
sentation of the data structure. Given these inputs, Korat 
generates all non-isomorphic data structures that satisfy the 
repOk predicate. Korat does so efficiently, by monitoring the 
execution of the repOk predicate and back-tracking only over 
those parts of the data structure that repOk actually reads. 

Korat relies on the purity of the repOk predicates but 
cannot statically check this. In general, writing repOk-like 
predicates is considered good software engineering practice; 
during the development of the data structure, programmers 
can write assertions that invoke repOk and check the consis- 
tency of the data structure at runtime. Of course, program- 
mers do not want assertions to change the semantics of the 
program, other than aborting the program when it violates 
an assertion. Therefore, the use of repOk in assertions pro- 
vides additional motivation for checking the purity of repOk 
methods. 

We analyzed the repOk methods for the following data 
structures: 

BinarySearchTree Binary tree that implements a set of com- 
parable keys. 

DisjSet Array-based implementation of the fast union-find 
data structure, using path compression and rank esti- 
mation heuristics to improve efficiency of find opera- 
tions. 

HeapArray Array-based implementation of the heap (prior- 
ity queues) data structure. 

BinomialHeap and FibonacciHeap Dynamic data structures 
that also implement heaps, but differ in complexity for 
certain operations. 

LinkedList Implementation of doubly-linked lists in the Java 
Collections Framework, a part of the standard Java li- 
braries. 

TreeMap Implementation of the Map interface using red- black 
trees. 



HashSet Implementation of the Set interface, backed by a 
hash table. 

Classic textbooks on algorithms and data structures, e.g., 
[12], present a detailed algorithmic description of all these 
data structures. LinkedList, TreeMap, and HashSet are 
from the standard Java Library. The only change the Korat 
developers performed was to add the 

corresponding repOk methods. We present the repOk method 
for BinarySearchTree in Appendix A. The source code for 
the other repOk methods has similar complexity. As the 
example from Appendix A shows, the repOk methods use 
complex auxiliary data structures: sets, linked lists, wrap- 
per objects, etc. Checking the purity of these methods is 
beyond the reach of simple purity checkers that prohibit 
pure methods to call impure methods, or to do any heap 
mutation. 

The first problem we faced while analyzing the data struc- 
tures is that our analysis is a whole-program analysis that 
operates under a closed world assumption: in particular, it 
needs to know the entire class hierarchy in order to infer the 
call graph. Therefore, we should either 1) give the analysis 
a whole program (clearly impossible in this case), or 2) de- 
scribe the rest of the world to the analysis. In our case, we 
need to describe to the analysis the objects that can be put 
in the data structures. The methods that our data structure 
implementations invoke on the data structure elements are 
overriders of the following methods: 

java.lang. Object . equals 
java.lang. Object .hashCode 
java.util .Comparable . compareTo 
j ava . lang . Ob j ect . toString 

We call these methods, and all methods that override 
them, special methods. We specified to the analysis that 
all special methods are pure. Moreover, these methods do 
not introduce new externally visible aliasing: any new ex- 
ternally visible path requires either creating an edge from 
the prestate (thus violating purity), or creating a path from 
a returned object. The methods hashCode, equals, and 
compareTo return primitive data, not objects; the method 
toString returns an immutable Java. lang. String that, we 
assume, cannot generate new aliasing. 

Therefore, the aforementioned special methods (and their 
overriders) are pure, and do not create new externally vis- 
ible paths. Hence, the analysis can simply ignore calls to 
these methods (even dynamically dispatched calls). 

We ran the analysis and analyzed the repOk methods for 
all the data structures, and all the methods transitively 
called from these methods. The analysis was able to ver- 
ify that all repOk methods mutate only new objects, and 
are therefore pure. On a Pentium 4 @ 2.8Ghz with 1Gb 
RAM, our analysis took between 3 and 9 seconds for each 
analyzed data structure. 

Of course, our results are valid only if all of the special 
methods are indeed pure. Our tool tries to verify that this is 
indeed true for all special methods that the analysis encoun- 
tered. Unfortunately, some of these methods use caches for 
performance reasons, and are not pure. For example, sev- 
eral classes cache their hashcode; other classes cache more 
complex data, e.g., java.util. AbstractMap caches its set of 
keys and entries (these caches are nullified each time a map 
update is performed). 
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Fortunately, our analysis can tell us which memory loca- 
tions the mutation affects. We manually examined the out- 
put of the analysis, and checked that all the fields mutated 
by impure special methods correspond to caching. 

7.3 Discussion 

From a theoretical point of view, our analysis is sound. 
However, in order to analyze complex data structures that 
use the real Java library, we had to sacrifice soundness to 
obtain a practical tool. More specifically, we had to trust 
that the caching mechanism used by several classes from the 
Java library is sound, i.e., it is just a performance issue. We 
believe that making reasonable assumptions about the un- 
known code in order to check complex known code is a good 
tradeoff. As our experience shows, knowing why exactly a 
method is impure is very useful in practice: this feature al- 
lows us to identify (and ignore) benign mutation related to 
caching. 

7.4 Pure Methods in the Java Olden Benchmark Suite 

We also ran the purity analysis on all the applications 
from the Java Olden benchmark suite [6,7]. Table 1 presents 
a short description of the applications we analyzed. They 
are all standalone applications. On a Pentium 4 @ 2.8Ghz 
with 1Gb RAM, the analysis time ranges from 3.4 seconds 
for TreeAdd to 7.2 seconds for Voronoi. In each case, the 
analysis processed all methods, user and library, that may 
be transitively invoked from the main method. 

Table 2 presents the results of our purity analysis. For 
each application, we counted the total number of methods 
(user and library), and the total number of user methods. 
For each category, we present the percentage of pure meth- 
ods, as detected by our analysis. Following the JML conven- 
tion, we consider that constructors that mutate only fields of 
the "this" objects are pure. As the data from Table 2 shows, 
our analysis is able to find large numbers of pure methods 
in Java applications. Most of the applications have simi- 
lar percentages of pure methods, because most of them use 
the same library methods. The variation is much larger for 
the user methods, ranging from 31% for Power to 89% for 
Perimeter. 

8. RELATED WORK 

Modern research on effect inference stems from the sem- 
inal work of Gifford, Lucassen, and Jouvelot on type and 
effect systems [19,26]. Most of the previous work on effect in- 
ference was done in the context of type systems and/or type 
inference, and mostly for functional languages. In contrast, 
we apply dataflow analysis techniques for purity checking of 
Java programs. Still, there are many common techniques, 
e.g., the construction of inter-procedural node mapping from 
our algorithm has a flavor of the unification algorithm used 
in type inference. 

Although the original work of Gifford and Luccasen was 
motivated by applications in program parallelization, most 
of the current work on effects is done in the context of pro- 
gram specification and verification. Two very popular such 
projects are the Java Modeling Language (JML) [23], and 
the Extended Static Checker for Java (ESC/ Java) [17]. 

JML is a Behavioral Interface Specification Language for 
Java, used as a common specification language in many re- 
search projects [5]. The annotations provided by the user 
are used for static program verification [34] or for generat- 
ing runtime assertions. Methods can be invoked from the 



Application 


Description 


BH 


Barnes-Hut N-body solver 


BiSort 


Bitonic Sort 


Em3d 


Models the propagation of electromag- 
netic waves through three dimensional 
objects 


Health 


Simulates a health-care system 


MST 


Computes the minimum spanning tree 
in a graph using Bentley's algorithm 


Perimeter 


Computes the perimeter of a region in a 
binary image represented by a quadtree 


Power 


Maximizes the economic efficiency of a 
community of power consumers 


TSP 


Solves the traveling salesman problem 
using a randomized algorithm 


TreeAdd 


Recursive depth-first traversal of a tree 
to sum the node values 


Voronoi 


Computes a Voronoi diagram for a ran- 
dom set of points 



Table 1: Applications from the Java Olden Bench- 
mark Set. 



Application 


All Methods 


User Methods 


count 


% pure 


count 


% pure 


BH 


264 


55% 


59 


47% 


BiSort 


214 


57% 


13 


38% 


Em3d 


228 


55% 


20 


40% 


Health 


231 


57% 


27 


48% 


MST 


230 


58% 


31 


54% 


Perimeter 


236 


63% 


37 


89% 


Power 


224 


53% 


29 


31% 


TSP 


220 


56% 


14 


35% 


TreeAdd 


203 


58% 


5 


40% 


Voronoi 


308 


62% 


70 


71% 



Table 2: Percentage of Pure Methods in the Java 
Olden benchmarks. For each application, we present 
the total number of user and library methods, the 
percentage of them that are pure, the number of 
user methods, and the percentage of pure user meth- 
ods. 



JML annotations, provided they are pure. JML also al- 
low the user to specify "assignable" locations, i.e., loca- 
tions that a method can mutate [29]. Currently, the purity 
and assignable clauses are either not checked at all or are 
checked using very conservative analyses: a method is pure 
iff 1) it does not do I/O, 2) it does not write any heap field, 9 
and 3) it does not invoke impure methods [22]. 

ESC/Java is a tool for checking properties of Java pro- 
grams. ESC/Java requires annotations in a specification 
language that is almost identical to JML. ESC/Java uses 
a theorem prover to do modular checking of the provided 
annotations. While checking a method body, ESC/Java as- 
sumes that the callers of the method satisfy their specifica- 
tion. Since ESC/Java also checks these callers, it ensures 
that all methods satisfy their specifications. A major source 



Constructors arc treated in a special way. 
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of unsoundness in ESC/Java is the fact that the tool uses 
purity and modifies annotations, but does not check them. 

There are two categories of approaches to solve this prob- 
lem: the first category relies on user-provided annotations; 
the second category, including our approach, relies on pro- 
gram analysis. An interesting approach from the first cat- 
egory is the work of Leino et al. on data groups [21,24]. 
Other approaches in this category use region types [14, 33] 
and/or ownership types [4, 9] to specify effects at the gran- 
ularity of regions, respectively at the granularity of owner- 
ship boundaries. In general, annotation based approaches 
are well suited for modular checking; they also provide ab- 
straction mechanisms to hide representation details. 

The analysis-based approach is appealing because it does 
not require additional user annotations. Even in situations 
where annotations are desired (e.g., to facilitate modular 
checking), static analysis can still be used to give the user 
a hint of what the annotations should look like. We briefly 
discuss two related static analyses. 

ChAsE [8] is a syntactic tool designed by Catafio and 
Huisman for modular checking of JML assignable clauses. 
For each method, the tool traverses the method code and 
collects write effects, using the assignable clauses from the 
specification of the invoked methods. Although lightweight 
and useful in many practical situations, ChAsE is an un- 
sound syntactic tool; in particular, unlike our analysis, it 
does not keep track of the values / points-to relation of vari- 
ables and fields, and ignores all aliasing. 

Spoto and Poll [32] propose an abstract interpretation [13] 
based static analysis that detects mutated locations. Their 
paper [32] contains compelling evidence that a static analysis 
for this purpose should propagate not only the set of mu- 
tated locations, but also information about the new values 
stored in those locations; otherwise, the analysis results are 
either unsound or overly-conservative. Our analysis uses the 
set of inside edges to keep track of the new value of pointer 
fields. Unfortunately, we are unaware of an implementation 
of the analysis of Spoto and Poll. 

The Fugue [15] protocol checker is another tool that could 
benefit from the use of our analysis. Fugue tracks the cor- 
rect usage of finite state machine-like protocols. Fugue re- 
quires user annotations in a rich type system that specifies 
the state of the tracked objects on method entry/exit. All 
aliasing to the tracked objects must be statically known. 
Many library methods 1) do not do anything relevant to the 
checked protocol, and 2) are too tedious to annotate. In 
addition, to promote code reuse, Fugue attempts to support 
library methods that work with both 1) tracked objects, and 
2) objects whose aliasing may not be fully known at compile 
time. Therefore, Fugue tries to find "[NonEscaping]" param- 
eters that are equivalent to our safe parameters. The current 
analysis/type checking algorithm from Fugue is very conser- 
vative as it does not allow a reference to a "[NonEscaping]" 
object to be stored in fields of locally captured objects (e.g., 
iterators) . 

Model checking of Java programs [10,35] could also ben- 
efit from our analysis. For example, the interleavings of 
two pure methods from two distinct threads are irrelevant. 10 

For this to be true, we also have to treat synchronizations as memory 
writes. 



The model checker can use this information to reduce the 
search space. Corbett [11] uses a related shape analysis to 
reduce the finite state models of multithreaded Java pro- 
grams by identifying thread-local objects. Interleavings of 
operations on thread-local objects are irrelevant. 

Ernst and Birka [2] proposed Javari, i.e., "Java with ref- 
erence immutability" , an extension to Java that allows the 
programmer to specify read-only parameters (called const 
in Javari). A type checker then checks the programmer an- 
notations. Read-only annotations for parameters are a great 
documentation asset, and can catch many practical bugs 
related to unintended mutation. To cope with caches in 
real applications, Javari allows the programmer to declare 
mutable fields. Such fields can be mutated even when they 
belong to a const object. Of course, the mutable annota- 
tion must be used with extreme caution. We encountered 
the same problem when analyzing real Java programs: many 
methods are impure simply because they use caching for 
performance issues. To make the tool practical, we expose 
the mutation on caches to the programmer, and allow the 
programmer to judge whether this mutation is allowed or 
not. Our tool could be a perfect companion for Javari: one 
can imagine using our tool to infer the read-only parame- 
ters for legacy code. A programmer can then refine these 
annotations and/or do small program changes to increase 
the number of read-only parameters. 

Other researchers, e.g. [18,28], have already considered 
the use of pointer analysis while infering side effects. How- 
ever, unlike previous analyses, our analysis uses separate 
abstractions (the inside node) for the objects allocated by 
the current invocation of the analyzed method. Therefore, 
our analysis focuses on prestate mutation, and supports pure 
methods that mutate newly allocated objects. 

9. CONCLUSIONS AND FUTURE WORK 

Recognizing method purity is important for a variety of 
program analysis and understanding tasks. We present the 
first implemented method purity analysis that is capable 
of recognizing pure methods that mutate newly allocated 
objects, including encapsulated objects that do not escape 
their creating method. Because this analysis produces a 
precise characterization of the accessed region of the heap, 
it can also recognize generalized purity properties such as 
read-only and safe parameters. 

Our experience using our implemented analysis indicates 
that it can effectively recognize many pure methods. It 
therefore provides a useful tool that can support a range of 
important program analysis and software engineering tasks. 

The most important future work direction concerns mak- 
ing the analysis better suited to the analysis of incomplete 
programs and libraries; to make this possible, one should 
have a specification for the missing parts of the program. 
The assignable clauses from JML are not sufficient: ac- 
cording to [32], we have to specify (in an abstract way) not 
only the mutated locations, but also the new aliasing created 
by the mutation. The points-to graphs contain this informa- 
tion, but they are too hairy to be used as a specification lan- 
guage. In Section 7, we used an ad-hoc solution in order to 
analyze consistency predicates for data structures; however, 
a more systematic solution is required. Ideally, the specifi- 
cation language should respect abstraction boundaries, i.e., 
it should not reveal private implementation details. 
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APPENDIX 

A. EXAMPLE repOk 

Figure 12 contains an example repOk method for a bi- 
nary search tree that implements a set. Each object of 
the class BinarySearchTree represents a binary search tree. 
The size field contains the number of nodes in the tree. 
Objects of the inner class Node represent nodes of the trees. 
The elements of the set are stored in the info fields. The 
elements must implement the interface Comparable, which 
provides the method compareTo for comparisons. 

In this example, repOk checks if the input is a valid binary 
search tree with the correct size. First, repOk checks if the 
tree is empty. If not, repOk checks that there is no sharing 
in the underlying graphs of nodes reachable from root along 
the left and right fields. It then checks that the number 
of nodes reachable from root is size. It finally checks that 
all elements in the left (right) subtree of a node are smaller 
(larger) than the element in that node. 

The method isTree uses a breadth-first traversal to check 
if the underlying object graph is a tree. This traversal keeps 
a set of visited nodes and a workList of nodes that still 
need to be traversed. Notice that the nodes are put in the 
set using the Wrapper class. We need this class because the 
standard java.util.Set compares the elements using their 
equals methods, whereas we want to compare the nodes in 
the set using comparison by object identity, ==. The use 
of the wrapper class is a typical way [25] to achieve this 
behavior. 

Our analysis finds that all three auxiliary methods-isTree, 
numNodes, and isOrdered-are pure, and also that repOk is 
pure. It is easy to establish that numNodes and isOrdered 
are pure, because they do not update any heap location. 
However, isTree writes several heap locations: it modifies 
the visited set and the workList list. Additionally, it cre- 
ates Wrapper objects for putting the nodes as elements of 
the set. Our analysis is precise enough to determine that all 
mutation occurs on new objects. 



import java.util.*; 

class BinarySearchTree { 

Node root; // root node 

int size ; // number of nodes in the tree 

static class Node { 

Node left; // left child 

Node right ; // right child 

Comparable info; // data 
} 

static final class Wrapper { 
Object o; 
Wrapper (Object o) { 

this.o = o; 
} 
public boolean equals (Object o) { 

if ( ! (o instanceof Wrapper)) return false; 

return this.o == ( (Wrapper) o) . o; 
} 
public int hashCodeO { 

return System. identityHashCode(o) ; 
} 
} 

boolean repOkO { 

// checks that empty tree has size zero 

if (root == null) return size == 0; 

// checks that the input is a tree 

if (! isTree ()) return false; 

// checks that size is consistent 

if (numNodes (root) != size) return false; 

// checks that data is ordered 

if (! isOrdered (root , null, null)) return false; 

return true ; 
} 

boolean isTree () { 

Set visited = new HashSetO; 

visited. add(new Wrapper (root) ) ; 

LinkedList workList = new LinkedList () ; 

workList .add (root) ; 

while ( IworkList . isEmptyO) { 

Node current = (Node) workList .removeFirst () ; 
if (current .left != null) { 

// checks that the tree has no sharing 

if (! visited. addCnew Wrapper (current . lef t) )) 

return false; 
workLi st . add ( current . lef t ) ; 
} 
if (current .right != null) -( 

// checks that the tree has no sharing 

if (! visited. addCnew Wrapper (current .right)) ) 

return false; 
workList .add(current .right) ; 
} 



return true ; 



} 



int numNodes (Node n) { 

if (n == null) return 0; 
return 1 + numNodesCn. lef t) 

} 



numNodes (n. right) ; 



boolean isOrdered (Node n, Comparable min, Comparable max) { 



if ((min != null kk n. inf o . compareTo (min) 

(max != null kk n. inf o . compareTo (max) 

return false; 
if (n.left != null) 

if ( ! is0rdered(n.left , min, n.info)) 
return false; 
if (n. right != null) 

if (! is0rdered(n. right , n.info, max)) 
return false; 
return true ; 



0) II 
0)) 



/* binary tree methods */ 



Figure 12: Code for Appendix A: binary search tree 
implementation with repOk method. 
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